1 METHOD FOR _ ASSIS TING THE ADMINISTRATION OF A DISTRIBUTED 

2 APPLICATION BASED ON A BINARY CONFIGURA TION FILE 

3 IN A COMPUTER SYSTEM 

[\\5 The present invention relates to a process for assisting in 

6 the administration of a distributed application based on a binary 

7 configuration file in a computer system. This process for 

8 assisting in the administration can especially be applied to a 

9 transaction processing manager like the one marketed under the 
(L 10 vname "Tuxedo." 

^p_ll fyyc* The "Tuxedo" application allows different software programs 

12^ that do not recognize one another, but that use a certain 

1^ protocol, to work together. 

lff 5 Generally, the "Tuxedo" application is a distributed 

1^; application, i.e., an application that runs on several machines 

iM! at the same time. A "machine" is the node of the network in which 

13 the servers of the "Tuxedo" application run, and the "master 

1^ machine" is the one that controls the "Tuxedo" application. Fig. 

lig 8 illustrates the operation of the "Tuxedo" application. When the 

2y| "Tuxedo" application is started up, the binary configuration file 

2T (TUXCONFIG) is loaded from the disk in the bulletin board (BB) of 

22 the master machine (Mm) . The bulletin board (BB) represents a set 

23 of data structures located in the shared memory and containing 

24 information on the transactions, the servers, the services and 

25 the clients belonging to the "Tuxedo" application. During the 

26 startup of the master machine (Mm) , the bulletin board (BB) is 

27 loaded into the memory of the master machine (Mm) from a binary 

28 "Tuxedo" configuration file (TUXCONFIG) . Then, it is distributed 

29 to the slave machines (Me) by the master process of the 

30 application, called the distinguished bulletin board liaison 



(DBBL) . Each machine of the application is under the control of 
process called a bulletin board liaison (BBL) . The distinguished 



communicates with the prooooooo (BBL) cb coordinate the updates 

A A 
of the bulletin board (BB) . The bulletin board liaison BBL is an 

administrative process that is responsible for maintaining an 

updated copy of the bulletin board (BB) in its own machine (Me) . 



implicitly defined by "Tuxedo." The bridge (BRIDGE) (1) is a 
process for managing communications between the servers of the 
"Tuxedo" application. Each machine is provided with a bridge 
implicitly defined by "Tuxedo." The server TMS (Transaction 
Manager Server) is a process that manages a validation protocol 
and recovery for transactions executed by several application 
servers. The listener module (tlisten, 3) is a process that 
manages the messages intended for the "Tuxedo" application in a 
given machine before the bridge process (BRIDGE) of this machine 
has been started. A listener module allows a machine to receive 
information coming from other machines. A listener module is 
required in each machine when the application is distributed. 

The "Tuxedo" application is created by the construction of 
binary configuration file that defines the architecture of said 
application (Fig. 7) . During the creation of the configuration 
file, an administrator defines the services (Se) provided by the 
application and assigns them to application servers (Sr) . The 
administrator then defines groups (G) and assigns a set of 
servers (Sr) . Finally, the administrator assigns groups (G) to a 
machine (M) • Each application must be given a minimum of one 
group (G) , one service (Se) and one server (Sr) . A machine (M) 





(Me) is under the control of a. process eeiied: BBL, 



A 
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1 can manage several groups (6) ♦ 

2 After the creation of a "Tuxedo" application, this 

3 application must be administered. The object of the invention is 

4 to create a system to assist in the administration of the 

5 "Tuxedo" application. The main steps involved in the 

6 administration of a "Tuxedo" application consist of: 

7 - a step for loading the binary configuration file of the 

8 "Tuxedo" application; 

9 - a step for starting listener modules when the "Tuxedo" 
10 application is a distributed application; 

M| - a step for starting the Tuxedo application; 

1^2; - a step for controlling the application. This consists of 

lQP displaying information and, if necessary, performing the required 

1j4i corrections; 

lS - a step for stopping the application; and possibly 

1% - a step for stopping the listener modules when they have 

158 been started. 

lS The administration of a distributed application can quickly 

l^S become very complex. In fact, before this administration can 

20 begin, the operator must activate a listener module in each slave 

21 machine on which he wishes to act. To do this, the administrator 

22 must first consult a file containing information on the 

23 activation of the listener modules. This file is generally 

24 stored, in a place that must be remembered, in each machine. 

25 Then, with the aid of this information, the operator must 

26 activate the listener module of each machine, one by one. Thus, 

27 if the application involves ten machines, the operator must 

28 activate the listener module in each of the ten machines, then at. 

29 the end of the application, deactivate the ten listener modules. 



This repetitive operation is long and tedious. 

Each administrator has his own solution for performing these 
tasks. The most common solution is to store in each machine, in a 
place that must be remembered, scripts for activating the 
listener modules, and to keep a paper copy of the configuration 
file. The administrator must make sure that the information is up 
to date at all times. Each time the configuration changes, he 
must not forget to print out a paper copy of the configuration 
file and update the scripts in the slave machines. 

Moreover, each time the operator wants to act on an element 
of an application, he must be able to quickly and accurately 
identify a given resource, such as for example, when stopping the 
server "servel" belonging to the group "groupl" in the machine 
"machl" . 

When the number of applications increases, these manual 
operations are the source of numerous errors. 



The object of the present invention is to eliminate the 
drawbacks of the prior art by offering a process for assisting in 
the administration of a distributed application of a transaction 
processing manager, based on the binary conf iguration file of the 
application, characterized in that said process comprises: 

- a step for decompiling the active configuration file of 
the master machine, 

- a step for retrieving information in the decompiled 
configuration file of the master machine (Mm) , 

- a step for checking the consistency of said application 
running on a given machine. 

According to another characteristic, said process makes it 
possible to manage at least one listener module (3) of any 
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1 machine of the application from another machine. 

2 According to another characteristic, the information related 

3 to said distributed application is extracted directly from the 

4 active configuration file of the master machine. 

5 According to another characteristic, the step for checking 

6 the consistency of said application consists of a comparison 

7 between information obtained from the configuration file of the 

8 master machine and information obtained from said current 

9 application running on another machine. 

10 According to another characteristic, said management of the 

1^ listener modules makes it possible to start and stop at least one 

listener module, to display information related to at least one 

131 listener module, to change the log of at least one listener 

ljf| module, to check 'the script of at least one listener module, and 

IS to update the script of at least one listener module. 
1* According to another characteristic, an administrator on any 

13 machine of the network can start or stop a listener module 

IS running on another machine of the network. 

According to another characteristic, said process makes it 

20 possible to activate several listener modules in a single 

21 operation. 

22 According to another characteristic, a graphical interface 

23 facilitates the management of the listener modules. 

24 According to another characteristic, said graphical 

25 interface makes it possible to display the structure of said 

2 6 application and to select a desired value from a list of values 

27 for the current configuration. 

2 8 According to another characteristic, when the file 

29 containing information on said application running on a given 
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1 machine (tlog) does not exist, the process generates it 

2 automatically in order to be able to use it during the next 

3 startup of the listener modules (3) • 

4 According to another characteristic, said displayed 

5 information related to at least one listener module comprises at 

6 least the name of said application, the logical name of the 

7 machine (LMID) on which said application is run, the 

8 identification of the administrator (UID) of said application, 

9 the address used by the listener module (NLSADDR) , the access 
10 path to the network of said application, and the access path to 
1^ the log file of said listener module (LLFPN) . 

ijfi Other characteristic and advantages of the present invention 

lOS will emerge more clearly with the reading of the following 

lf|j description given in reference to the attached drawings, in 

lj£ which: 

1* - Fig. 1 represents a window of the graphical interface that 

1® offers access to the main commands for managing the modules; 
iM - Fig. 2 represents a window of the graphical interface 

W according to Fig. 1 that makes it possible to activate one or 

20 more listener modules; 

21 - Fig. 3 represents a window of the graphical interface 

22 according to Fig. 1 that makes it possible to stop one or more 

23 listener modules; 

24 - Fig. 4 represents a window of the graphical interface 

25 according to claim 1 that makes it possible to display 

26 information related to a listener module of a given application; 

27 - Fig. 5 represents a window of the graphical interface 

28 according to claim 1 that makes it possible to check the script 

29 of a listener module of a given application; 



1 - Fig. 6 represents a window of the graphical interface 

2 according to claim 1 that makes it possible to update the script 

3 of a listener module in a given machine of a given application; 

4 - Fig. 7 represents the general structure of a distributed 

5 application of a transaction processing manager; 

6 - Fig. 8 represents an exemplary application of a 

7 /v transaction processing manager. 

^ 8 The following is a non-limiting exemplary specification of a 

9 configuration file. This configuration file, presented in 

10 Appendix 1, relates to the "Tuxedo" application. It is divided 

\J 1#| into &±x sections, (resources, machines, groups, servers, 

f\J^ A roofing oncl 

L/X?I services, network) . 

yy a 

1® The resources section contains general information related 

lfk to the application. This information is common to all the 

1^; machines and is constituted by the following parameters: 

1!| - IPCKEY, which represents a digital key identifying the 

111 shared memory segment in which the application structures are 

l)S stored. Thanks to this digital key, a given application cannot be 

l^f in conflict with other applications; 

20 - MASTER, which represents the master machine; 

21 - DOMAINID, which represents the domain of the application; 

22 - MAXACCESSERS, which defines the maximum number of people 

23 that can access the application; 

24 - MAXSERVERS, which defines the maximum number of servers 

25 that can be connected with the application; 

2 6 - MAXSERVICES, which defines the maximum number of services 

27 that can be connected with the application; 

2 8 - OPTIONS, which makes it possible to indicate whether the 

29 application is running in a local area network; 
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1 - MODEL, which makes it possible to indicate whether the 

2 application is or is not distributed. 

3 The machines section contains information on each machine 

4 (puce, trifide, zig, orage) of the network. This information is 

5 constituted by the following parameters: 

6 - LMID (Logical Machine ID) , which defines the logical name 

7 of the machine, i.e., the name used internally by the application 

8 in place of the network name; 

9 - TUXDIR, which specifies the access path to the 
10 installation directory of the "Tuxedo" software; 

1A - APPDIR, which specifies the access path to the application 

l^J servers, i.e., the path leading to the programs of the 

1120 application (for example, the programs related to the "TUXEDO" 

l|| application) ; 

lS - TUXCONFIG, which specifies the absolute access path to the 

binary configuration file TUXCONFIG, which contains information 

IS on the application; 

- ENVFILE, which specifies the access path to the file 
containing the environment variables for the servers and the 

20 clients of a given machine; 

21 - ULOGPFX, which specifies the access path to the file 

22 "ULOG" , which contains information on the history of the 

23 application. 

24 The groups section is the section in which each machine is 

25 assigned to a group. In the example of Appendix 1, there are four 
2 6 groups. A group is a set of servers that provide related 

27 services. In th simplest case, a group is constituted by only 

28 one server. All the servers of a group must run on the same 

29 machine. An application must comprise at least one group. 
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1 The servers section provides information on each server. A 

2 server is a module that provides services. In the example of 

3 Appendix 1, there are four servers. In the simplest case, a 

4 server provides only one service. An application must be provided 

5 with at least one server. The server section provides the 

6 following information: 

7 - SRVGRP, which defines the group with which the server is 

8 affiliated; 

9 - SRVTD, which defines the identification number of the 
10 server; 

lgj - MIN, MAX, which indicates the maximum and minimum 

l2t occurrences of this server; 

1& - RQADDR, which defines the name of the message queue used 

ljfj for the sending of a message; 

1^: - in REPLYQ, the administrator decides on the existence of a 

16 response queue; 

1£0 - CLOPT, which indicates the startup options of the server 

lg (available services, priority, etc.). 

l^tj In the services section, the administrator can specify the 

2 0 services. A service is a set of functions that respond to service 

21 requests issued by end users of the application. If the 

22 administrator wishes to indicate optional values that are 

23 different from the default values, the services must necessarily 

24 be defined. 

25 The network section contains, for each machine: 

26 - the complete address used by the bridge process (BRIDGE) , 

27 called the "Network Address" or "NADDR" . The first four digits 

28 (0002 in the example of Fig. 4) represent the communication 

29 protocol used ("tcp" in the above example) . The next four digits 
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1 represent the port number used by the process and the subsequent 

2 digits represent the network address of the machine; 

3 - the access path to the bridge (BRIDGE) of the machine. The 

4 bridge is a process for managing communications between the 

5 servers of the application. It is used to boot up the 

6 application. Each machine is provided with a bridge. 

7 - the complete address of the listener module, called 

8 "NLSADDR" . The first four digits represent the communication 

9 protocol used. The next four digits represent the port number 

10 used by the listener module, which must be different from the one 

11 used by the bridge process (BRIDGE) • The subsequent digits 
132; represent the network address of the machine. 

1® The essential characteristic of the invention is that the 

lf4j information related to the application is extracted directly from 

lMj the active file of the master machine. An administrator on any 

1^6 machine of the network can control the execution of the command 

lgp "get_tuxval" in the master machine belonging to the 

]j& administrator, as represented on page [27] of Appendix 2. 

1^ The subroutine "get_tuxconf ig" of the program used in the 

2 0 implementation of the process for assisting in the administration 

21 of a distributed application searches on the hard disk of the 

22 master machine for the active configuration file of the 

23 application. The latter is then decompiled by means of the 

24 command 11 tmunloadcf 11 (Page [28] of Appendix 2), lines 85 through 

25 99. 
26 

27 get_tuxconf ig() { 

2 8 if [ -s tuxconf . tmp.$appname ] 

2 9 then 

3 0 cat tuxconf . tmp . $appname 
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1 else 

2 rm - f tuxconf . tmp . * 

3 prog= " $Env" 1 

4 $TUXDIR/bin/tmunloadcf 

5 echo "\nexit $?" 

6 ' 

7 #print -r "$prog" > prog 

8 rsh "$MASTER" -1 " $ ADMIN" »$prog n | tee tuxconf. 

9 tmp . $appname 

10 fi 

11 get_tlistenlog 

12 } 
13 

14 The subroutine "gettuxval" of this program (Page [28] of 

l|h Appendix 2, lines 112 through 183) extracts parameters such as 

1^: LMID, APPDIR, TUXCONFIG, TUXDIR, ROOTDIR, ULOGPFX, NLSADDR, UID 

3g and BRIDGE from the binary configuration file of the application 

l?8j obtained by means of the subroutine "gettuxconf ig" . 

•8 

2J5 get tuxval ( ) { 

2g| gettuxconf ig | \ 

2m sed -e "s/=/ /g» -e ■s/'V/g' -e 's/\\\\/0/g' | awk ■ 

2| 

2_J§ The values of the parameters sought are first initialized. 

25 To do this, associative matrices called "tuxconf ig_section" are 

26 created. 
27 

28 BEGIN { 

29 tuxconf ig_section ["♦RESOURCES"] = 1 

30 tuxconfig_section["*MACHINES"] = 2 

31 tuxconf ig_sect ion ["*GR0UPS"] = 3 

32 tuxconf ig_sect ion [■* SERVERS"] = 4 

33 tuxconf ig_section["*SERVICES"] = 5 

34 tuxconfig_section["*ROUTING"] - 6 

35 tuxconfig_section["*NETWORK"] = 7 
36 

37 An index is associated with each matrix. The parameters 
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1 sought are located in different sections of the configuration 

2 file. For example, for the "Tuxedo" application, these different 

3 sections, which number seven, are called "Resources," "Machines," 

4 "Groups, "Servers," "Services, 11 "Routing" and "Network." In order 

5 to be able to extract the parameters that the computer needs, it 

6 must be able to mark the place where it is found in the 

7 configuration file. In this program, when the field number (NF) 

8 is equal to 1, the computer is found at the beginning of a 

9 section. 
10 

11 NF == 1 { 

1W if ( $1 in tuxconf ig_section ) { 

13: section = tuxconf ig_section [$1] 

lM next 

# } 

m > 

m 

ljBf If the computer is in section 2 and the second word is LMID, 

1^ the computer extracts the logical name of the machine (LMID) on 

2l£K which the administrator is working. 

2j 

2f] section == 2 && $2 == " LMID { # MACHINES section 

23 if ( $3 == machine) { 

24 printf "uname=%s\n" , $1 

25 mach_found=l 

26 } 

27 else { # reset mach_found for further machines 

2 8 mach_f ound = 0 
29 } 

3 0 next 

31 } 
32 

33 If the computer is in section 2 and the first word is 

34 APPDIR, it extracts the access path to the directory under which 

35 the servers are bootstrapped. 
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2 section == 2 && $1 == "APPDIR" && mach_f ound==l { 

3 printf ,, appdir=%s\n" , $2 

4 appdir = $2 

5 next 

6 } 
7 

8 Proceeding in the same way, the computer will successively 

9 extract, in the machines section of the configuration file, the 

10 absolute access path to the binary configuration file 

11 (TUXCONFIG) , the access path to the installation directory of the 

12 Tuxedo software (TUXDIR or ROOTDIR) , information on the history 
13* of the application (ULOGPFX) , and in the network section, the 
1M address of the bridge of the machine (NLSADDR) . 

M 

M section == 2 && $1==" TUXCONFIG" && mach_found == 1 { 

printf ,, tuxconfig=%s\n", $2 

l^t next 

2& section == 2 %% $1==" TUXDIR" && machf ound==l{ 

231 printf " tuxdir=%s\n" , $2 

22j next 

23 } 

2§ section == 2 && $1==" ROOTDIR" && machf ound==l { # for V4 

2%' printf " tuxdir=%s\n" , $2 

26 next 

27 } 

28 section == 2 && $1==" ULOGPFX" && mach_f ound==l { 

29 ulogpfx=l; printf "ulogpfx=%s\n" , $2 

30 next 

31 } 

32 section == 7 && NF == 1 { 

33 if ( $1 == machine ) 

34 { ma ch_ found = 1} 

35 else { # reset mach_found for other machines 

36 mach_f ound = 0 

37 } 

38 next 

39 } 
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1 section == 7 && $1=="NLSADDR" && mach_f ound==l { 

2 printf "nlsaddr=%s\n" , $2 

3 next 

4 } 
5 

6 The program executes a loop in this subroutine for each 

7 machine until the computer finds the current machine. Then, the 

8 computer obtains, in the resources section of the configuration 

9 file, the identification of the user of the application (UID) . 
10 

11 section == 1 && $1 == "UID" {printf "uid=%s\n» , S2; next } 
12 

15, If no value has been defined for the UID in the 

lJP configuration file, the UID of the person who built the 

US application is used. Next, the computer finds in the network 

section of the configuration file the access path to the bridge 

iff (BRIDGE) of the machine. 
1=8 

iSP section == 7 && $1==»BRIDGE" && machf ound==l { 

2fl The parameter ULOGPFX representing the history of the 

2J| machine is an optional value. When it does not exist, the 

23 computer will generate a file called "ULOG" in the directory 

24 APPDIR containing information on the manipulations performed on 
2 5 the application. 

26 

27 if ( ulogpfx == 0 ) { 

28 printf "ulogpfx=%s/ULOG\n" , appdir } 

29 } 1 machine =$machine appname=$appname 

30 lang="sed -e "s/=/ /g" -e "s/'/ /g» -e "s/;/ /" $ConfDir/ 

31 $appname.tux | awk 1 

32 $1 == " LANG" {printf "lang^ 1 , $2}'" 

33 } 
34 
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1 In addition, the computer needs the working language of the 

2 application, represented by the parameter LANG, as well as the 

3 value "tlog" . The parameter LANG is found in the user's 

4 configuration file. 
5 

6 lang="sed -e "s/=/ /g" -e "s/'//g" -e "s/;/ /" 

7 $ConfDir/$appname. tux | awk 1 

8 $1 == "LANG" {printf "lang=", $2}'" 
9 

10 The value "tlog" refers to the file "tlistenlog . <name of 

11 the application> . <name of the machine>" containing the name of 

12 the history file of the listener module, 

O 

±M In the subroutine gettuxval, the program has gathered all 

uj 

1^ of the environment variables it needs to be able to start the 

lj^ process for assisting in the administration of a distributed 

Mi application. This process makes it possible, in addition to 

L7 starting and stopping one or more listener modules, to display 

ijg information on one or more listener modules, to change the log of 

W one or more listener modules, to check the script of one or more 

2J| listener modules, and finally, to update the script of one or 

2"¥ more listener modules (Fig. 1) . 

22 The process for assisting in the administration of a 

23 distributed "Tuxedo" application is provided with a graphical 

24 interface that allows access to the commands of the transaction 

25 processing manager. To execute a task, the administrator is not 

26 required to enter commands; he need only click on icons to call 

27 up menus and indicate values via dialog boxes. The assisting 

28 process is controlled by menus, structured in tre form. The 

29 selection of an option in the main menu results in the display of 
3 0 the associated lower level menu. This process is repeated until a 
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1 pop-up dialog box is displayed, in which the administrator must 

2 enter parameter values. In order to be able to manage the 

3 listener modules of the distributed "Tuxedo" application, the 

4 administrator selects, from the main menu "Tuxedo Commands," the 

5 functions "Tuxedo Commands," "Start/Stop Tuxedo Configuration," 

6 "Set up a Tuxedo Application" and "Manage the Listener 

7 Processes." The selectable functions "Start Listener Processes," 

8 "Stop Listener Processes," "Change/Show Listener Process 

9 Parameters," "Show currently running Listener Processes," "Check 
10 consistency of Listener Process scripts with TUXCONFIG Level" and 
1CD "Update Listener Process to TUXCONFIG Level" appear in the window 
lgj of the graphical interface (Fig. 1) . To start listener modules, 
1% the administrator must select the command "Start Listener 

l{4j Processes" by positioning the cursor of his mouse on the box (11) 

llg and pressing on the left button of his mouse. The window of Fig. 

W>| 2 appears after the selection. If an application has been 

lj$j predesignated, its name is displayed in the box (21) . If not, the 

W administrator is informed by the blinking marker of the cursor 

1J| that he must provide one. To do this, the administrator can 

20 either click on the "List" button (23) in order to display the 

21 list of the stored applications and select one of them, or 

22 explicitly enter the name of the desired application. Next, the 

23 administrator is informed by the blinking marker of the cursor in 

24 the box (22) that he must indicate the name(s) of the machine (s) 

25 in which a listener module must be started. In the same way, the 

26 list of the machines comprised in said application can be 

27 obtained by clicking on the "List" button (23) . In order to 

28 validate the machines selected, for example by being highlighted, 

29 the administrator must click on the "OK" button (24) . The command 
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1 for starting the listener module is obtained by selecting the 

2 "Command" button (25) . The "Reset" button (26) makes it possible 

3 to reset the values of the boxes (21) and (22) • The "?" button 

4 (28) offers online help to the administrator. 

5 For each machine designated in the list of machines, the 

6 computer obtains information on the application in the 

7 configuration file of the master machine, and a history file 

8 called " tlistenlog. <name of the application> . <name of the 

9 machine>" containing information on the application currently 
10 running on this machine. First, the computer checks to see 

1£| whether the listener module has already been started in the 

%% machine. If this is the case, the message "Listener already 

ljg; running on <name of the machine>" is printed on the screen. 

Iffi Otherwise, if a local file exists, the computer executes it and 

lM prints the message "Listener started on the machine" if the 

1:6 command succeeds. If the command fails, the computer prints the 

lH message "Listener starting failed on <name of the machine>". If 

lj§ the local file does not exist, the computer generates a file 

"tlistenlog . <name of the application> . <name of the machine>" 

20 in the directory APPDIR, executes it, and reports the result as 

21 before. This file contains information on the current application 

22 and will be used in the next startup of the listener modules. 

23 This corresponds to lines 652 through 698 on page [36] and to 

24 lines 699 through 719 on page [37] of Appendix 2. 
25 

26 startlistproc) 

27 appname=$l; shift 

28 list="$*" 

29 set_environ 

30 loop_status=0 

31 exit status=0 
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1 for machine in $list 

2 do 

3 echo 11 \n Machine: $machine \n" 

4 ge t_ tuxva 1 > " appname . tux " 

5 get_tllog 

6 . . /appname . tux 

7 progl=" 

8 TUXDIR=$tuxdir; export TUXDIR 

9 ROOTDIR=$tuxdir; export ROOTDIR # V4 

10 APPDIR=$appdir; export APPDIR 

11 TUXCONFIG=$tuxconfig; export TUXCONFIG 

12 PATH=${PATH}:\$TUXDIR/bin:\$APPDIR; export PATH 

13 LANG=$lang; export LANG 

14 LIBPATH=${LIBPATH} :$tuxdir/lib; export LIBPATH 

15 COLUMNS=200; export COLUMNS 

lg ps -eF '%u %p %a' | awk"\$3 ~ |"tlisten\" && \$0 - 
im \$nlsaddr\» {exit l}' 

im if [ \$? = 1 ] 

ljj then 

25; echo V'Listener already running on $machine\" 

2;E echo exit 0 

2g exit 0 

23 fi 

2B if [ -f $appdir /tl is ten. $ appname. $machine ] 

2f5t then 

2j& . $appdir/ tlisten . $ appname $machine 

2f ps -eF "%u %p% a" | awk '\$3 ~ \"listen\» && \$0 ~ 

^ \$nlsaddr\" {exit l}' 

2¥ if [ \$? = 1 ] 

30 then 

31 echo V'Listener started on $machine\" 

32 echo exit 0 

33 else 

34 echo V'Listener starting failed on $machine I ! ! \ " 

35 echo exit 1 

36 fi 

37 else # create the script file & exec it 

38 echo \"$tuxdir/bin/ tlisten -d $bridge -1 $nlsaddr -u $uid 

39 -L $tllog\" > $appdir/ tlisten. $appname. $machine 

40 chmod ug+x $appdir/ tlisten . $ appname. $machine 

41 . $appdir/ tlisten. $ appname. $machine 

42 ps -eF "%u %p %a'|awk'\$3 ~ \"tlisten\" && \$0 ~ 

43 V'nlsaddrV {exit l}' 
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1 if [ \$? = 1 ] 

2 then 

3 echo \" Listener started on $machine\" 

4 echo exit 0 

5 else 

6 echo V'Listener starting failed on $machine ! ! ! \ " 

7 echo exit 1 

8 fi 

9 fi" 

10 #echo "$progl M > progl 

11 if [ -z $uname" ] 

12 then 

13 [print "Host $machine not found" 

14 exit 1 

15 fi 

lfi rsh Suname" -1 $ ADMIN" "$progl" | awk ■ 

13| NR == 1 {line = $0} 

lM NR > 1 ( print line; line = $0 } 

lg END {if (subO'^exit", "", line)) exit line; print line; 

2& exit -1}' 

2^3; loop_status=^expr $loop__status\ | $?^ 

2g done 

Z$ exit $loop _status 

m ;; 

m 

2p| To stop a listener module, the administrator selects, from 

2f% the main menu for managing listener modules, "Manage the Listener 

28 Processes", the function "Stop Listener Processes" by positioning 

2 9 his curser on the box (12) (Fig. 1) . The window of Fig. 3 

30 appears. It makes it possible to indicate, in a first box (31), 

31 the name of the application, and in a second box (32) , the name 

32 of the machine or machines. By clicking on the "List" button 

33 (33) , a list of the applications stored or a list of the machines 

34 related to each application can be obtained depending on the 

35 position of the blinking position marker (34) . For each machine 

36 of the application, the computer prints the name of the machine 

37 for which the listener module is stopped. This selection on the 
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1 screen via the graphical interface starts the program steps 

2 "stoplistproc" during which the program obtains information, in 

3 the station in which the stop procedure is initiated, using 

4 get_tuxval on the application contained in the configuration file 

5 of the master machine (Page [37] of Appendix 2, lines 720 through 

6 762). 
7 

8 stoplistproc) 

9 appname=$l; shift 

10 list="$*" 

11 s e t_envi r on 

12 loop_status=0 
l|£j exit_status=0 

1& for machine in $list 

m do 

lijp echo "\n Machine: $machine \n" 

1^ ge t_ tuxva 1 > " appname . tux 11 

ljt{ . . /appname • tux 

l^J progl = " 

2JT COLUMNS=2 00: export COLUMNS 

2m ps -eF '%u %p %a'|awk "\$3 ~ \"tlisten\» && $0 ~ 

2S \"$nlsaddr\" {print \$2; exit 0} | read pid 
m if [ -n\»\$pid\» ] 

then 

2f kill -9 \$pid > /dev/null 

2%' status=\$? 

27 if [ \$status -eq 0 ] 

2 8 then 

29 echo \ 11 Process \$pid killed on $machine\" 

3 0 echo exit 1 

31 else 

32 echo V'Failed to stop listener on $machine ! ! ! \ " 

33 echo exit 1 

34 fi 

35 else 

3 6 echo \"No Listener running on $machine\" 

37 echo exit 1 

38 fi" 

39 if [ -z "$uname" ] 

4 0 then 
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1 print "Host $machine not found" 

2 exit 1 

3 fi 

4 rsh "$uname" -1 "$ ADMIN" f, $progl" | awk 1 

5 NR == 1 {line = $0} 

6 NR > 1 { print line; line = $0 } 

7 END {if (subC'^exit", line)) exit line; print line; 

8 exit -1}' 

9 loop_status= "expr $loop_status \|$?^ 

10 done 

11 exit $loop_status 

12 ;; 
13 

14 If a process called "tlisten" belonging to the current 

application is running on this machine, the computer kills it and 

lM prints the message "Process <process identifier (PID) > killed on 

lffl <name of the machine>; otherwise it prints the message "Failed to 

Iffl stop listener on <name of the machine>". 
13! Furthermore, this process for assisting in the 

2J) administration of an application makes it possible to display 

2pB information related to a listener module. To do this from the 

2£k main menu for managing listener modules "Manage the Listener 

2F§ Processes," the administrator need only select the function 

24 "Change/Show Listener Processes Parameters" in the box (13) of 

25 the window presented in Fig. 1. The window of Fig. 4 appears. The 
2 6 administrator must indicate, in the box (41) , the name of the 

27 application, and in the box (42), a machine name. As a result of 

28 this indication, the other boxes (43 through 46) of the window 

29 will show the values of parameters such as: 

30 - the identification of the administrator (UID) , 

31 - the complete address of the listener module, composed of 

32 the address of the machine and the number of the port it is using 

33 (NLSADDR) , 
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1 - the access path to the network, 

2 - the full access path to the log file of the listener 

3 module (Listener Logfile Full Path Name, LLFPN) . 

4 All of this information is extracted from the file TUXCONFIG 

5 of the master machine. This information cannot be changed by this 

6 command, with the exception of LLFPN. Appendix 2 presents, on 

7 lines 570 through 579 on page [35] , the part of the program 

8 corresponding to the execution of the command for changing the 

9 LLFPN. 
10 

11 chglisten) 

1W appname = $ 1 

l)fj machine=$2 

ijj shift 2 

lg if [ $# -gt 0 ] 

lgf then 

im echo "TLLOG $machine $1" > 

1M $Conf Dir/tlistenlog/$appname • $machine 

19 fi 

2g exit $? 

2S ; 

2|j 

2% 3 In order to be able to display the active listener modules 

25 of the application, the administrator must select the function 

26 "Show currently running Listener Processes" by clicking on the 

27 box (14) of the window of Fig. 1. The computer displays the list 
2 8 of the machines of the application on which a listener module is 
2 9 active and the process identifier (PID) belonging to the 

30 configuration of the network. Appendix 2 presents, on lines 764 

31 through 768 on page [37] and on lines 769 through 809 of page 

32 [38] , the part of th program corresponding to the display of the 

33 list of active listener modules, which us s the function 
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1 get_tuxval . 
2 

3 running list) 

4 appname=$l 

5 loop_status-0 

6 set_environ 

7 list _lmids='get_tuxconf ig| \ 

8 sed -e »s/»//g" -e 1 s/»//g' -e s/\\\\/0/' -e s/\*//" | awk ' 

9 BEGIN { networks 0 } 

10 {line = $0} 

11 NF == 1 {if (network == 1) print $1} 

12 $1 == "NETWORK" {network = 1} 

13 END {if (sub( ,,A exit", "'Mine) ) exit line; exit -1 } 1 "* 

14 for machine in $list_lmids 

15 do 

l^f ge t_ tuxva 1 > " appname . tux " 

• . /appname . tux 

ijitj progl=" 

IJh TUXDIR=$tuxdir; export TUXDIR 

2m LIBPATH=${LIBPATH}:$tuxdir/lib; export LIBPATH 

21D ROOTDIR=$tuxdir; export ROOTDIR # V4 

2® APPDIR=$appdir; export APPDIR 

23 TUXCONFIG=$tuxconfig; export TUXCONFIG 

29 PATH=${PATH} : \$TUXDIR/bin: \$APPDIR; export PATH 

2jfl LANG=$lang; export LANG 

2|( COLUMNS=200; export COLUMNS 

2jj ps -eF '%u %p %a' | awk f \$3 - \" tlisten\" && \$0 - 
2M | "$nlsaddr\" {print \$2}'| read pid 

29 if [ -n \»\$pid\" ] 

30 then 

31 echo V'Listener running on $machine: pid = \$pid\" 

32 echo exit 0 

33 else 

34 echo \"No Listener running on $machine\" 

35 echo exit 0 

36 fi» 

37 if [ -z $uname" ] 
3 8 then 

39 print "Host $machine not found" 

40 exit 1 

41 fi 

42 rsh "$uname" -1 " $ ADMIN" "$progl" | awk 1 
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1 NR == 1 {line = $0} 

2 NR > 1 { print line; line = $0 } 

3 END { if (sub("^exit", "", line)) exit line; print line; 

4 exit -1}" 

5 loop_status="expr $loop status\ | $?" 

6 done 

7 exit $loop_status 
8 

9 

10 The administrator can also check the script of a listener 

11 module. By selecting the function "Check consistency of Listener 

12 Process scripts with Tuxconfig" in the box (15) of the window 

13 represented in Fig. 1, the window of Fig. 5 appears. The 

lj^ administrator must enter the name of an application in the box 

iM (51) and the name of a given machine in the box (52) . A list of 

1|6| the applications and the machines is made available to the 

iJij administrator by the "List" button (53) . The program compares the 
information contained in the file TUXCONFIG of the master machine 

l|i and extracted by the function "get_tuxval" with the information 

2j5j contained in the file "tlisten. (name of the application) . (name of 

2%' the machine) 11 located in the directory APPDIR of the machine and 

7M gives the result of this comparison. Appendix 2 presents, on 

23 lines 580 through 631 of page [35] and on lines 632 through 651 

24 of page [36] , the part of the program corresponding to the 

25 checking of a script of a listener module, which makes it 

2 6 possible to indicate the mismatches between the parameters of the 

27 files, for example by printing "BRIDGE values mismatch" for the 

2 8 bridge. 
29 

30 chklistscript) 

31 appname=$l 

32 machine= $2 

33 set envi ron 
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1 get_tuxval > "appname. tux" 

2 get_tllog 

3 . . / appname . tux 

4 prog=" 

5 if [ -f $appdir/ tlisten. $appname . $machine ] 

6 then 

7 cat $appdir/ tlisten . $ appname ♦ $machine 

8 echo \"\\nexit 0\" 

9 else 

10 echo \"\\nexit 1\" 

11 fi" 

12 if [ -z »$uname" ] 

13 then 

14 print "Host $machine not found" 

15 exit 1 

16 fi 

1^ rm -f tlscript . $ appname $machine 

1181 rsh $uname" -1 11 $ ADMIN 11 "$prog" | tee tlscript. 
l§f $appname . $machine > /dev/null 

2j [ $? -ne 0 ] && exit 1 

2jt [ -s tlscript. $ appname . $machine ] && cat tlscript. 
2% $ appname . $machine | \awk 1 

2j END {if ( $2 == "1" ) exit -l}' 

2f§ [ $? -eq -1 ] && exit 1 

218 [ -s tlscript . $appname . $machine ] && cat tlscript. 

2W $ appname . $machine | \ 

2© awk ' 

2W $1 - "tlisten" { 

29 mismatch = 0 

30 fexec=sprintf ("%s/bin/ tlisten" , tuxdir) 

31 if ($1 !=fexec){ 

32 print "tlisten command full pathnames mismatch" 

33 printf "\tscript : \t%s\n» , $1 

34 printf "\tconf ig: \t%s\n" , fexec 

35 mismatch +=1 

36 } 

37 for (i=2; i <= NF; i++) { 

38 if (($i == "-d") && ($(i+l) != bridge)){ 
3 9 print "BRIDGE values mismatch" 

40 printf "\tscript : \t%s\n" , $ (i+1) 

41 printf "\tconf ig: \t%s\n" , bridge 

42 mismatch +=1 

43 } 
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1 if (( $i == "-1") && ($(i+l) ! =nlsaddr) ) { 

2 print "NLSADDR values mismatch" 

3 printf " \tscript : \t%s\n" , $(i+l) 

4 printf "\tconf ig: \t%s\n" , nlsaddr 

5 mismatch +=1 

6 } 

7 if (($i == »-u") && ($(i+l) != uid)){ 

8 print "UID values mismatch" 

9 printf "\tscript : \t%s\n" , $(i+l) 

10 printf "\tconfig:\t%s\n", tllog 

11 mismatch +=1 

12 } 

13 }} 

14 END { 

15 if ( mismatch == 0 ) 

1Q printf "Script File is up-to-date for %s\n" , 

133 machine 

llSl else 

lgj print f"\nScript File is NOT up-to-date for 

2;j§{ % s \n 11 , machine 

2;i{ } 1 tllog=$tllog machine=$machine bridge=$bridge \ 

2g nlsaddr=$nlsaddr uid tuxdir=$tuxdir 

2j exit $? 

m ;; 
2^ 

2g A script of a listener module can also be updated by 

2"¥ selecting the function "Update Listener Process scripts to 

28 TUXCONFIG Level." A script of a Tuxedo listener module makes it 

2 9 possible to start a listener module. It suffices to integrate a 

30 script of this type into the startup sequence for a given machine 

31 in order for the listening machine to be started automatically at 

32 the same time as the machine. In the window represented in Fig. 

33 6, the administrator enters in the box (61) the name of an 

34 application, and in the box (62) the name of one or more 

35 machines. The program, by calling the subroutine "get_tuxval" , 

3 6 obtains all of the information it needs in the binary 

37 configuration file extracted by the subroutine "get_tuxconf ig" 
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1 and creates a file corresponding to it in the directory APPDIR 

2 under the name "tlisten. (name of the application) . (name of the 

3 machine) • Lines 810 through 831 of Appendix 2, page [38] present 

4 the part of the program corresponding to the execution of the 

5 command for updating a script of a listener module. 
6 

7 updtlistscript) 

8 appname=$l 

9 machine=$2 

10 set_environ 

11 get_tllog 

12 get_tuxval > "appname. tux" 
13^ . . /appname . tux 

1% prog= " 

lK echo \" $tuxdir/bin/tlisten -d $bridge -1 $nlsaddr -u $uid -L 

■45 $tllog\" > $appdir/tlisten. $appname. $machine 

lfi chmod ug+x $appdir/ tlisten. $appname. $machine 

W echo exit \$?" 

M if [ -z "$uname" ] 

2@ then 

2!^ print "Host $machine not found" 

2j2! exit 1 

2gj fi 

2jj rsh "$uname n -1 "$ ADMIN" »$prog" | awk ' 

25 NR == 1 {line = $0} 

2S NR > 1 { print line; line = $0 } 

27 END {if (sub(" A exit'\ "'Mine) ) exit line; print line; exit 

28 -1}' 

2 9 exit $? 
30 

^ , th e a rt aro also part of the opirit of tho invontion. ' 
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